In asymmetric digital subscriber line (ADSL) and very high speed digital subscriber line (VDSL) systems, retransmission (ReTx) can be optionally utilized for ensuring quality of transmission for latency-insensitive data, such as video. Techniques for performing retransmission are provided in the G.inp recommendation. The retransmission scheme used in xDSL systems supports both asynchronous transfer mode (ATM) and packet transfer mode (PTM) protocols and has been designed such that elementary frames that can be retransmitted are formed in the physical layer (PHY). Generally, for ADSL systems, it has been proposed that retransmission be implemented only in the downstream direction, whereas for VDSL systems, retransmission may either be implemented in strictly the downstream direction or in both the downstream and upstream directions.
Generally, a transmitter that supports a retransmission scheme includes a retransmission queue for storing elementary frames in order to have access to previously-sent elementary frames in the event that a request for retransmission is received. A request for retransmission is contained in a retransmission return channel (RRC) message, which contains information on which elementary frames have been incorrectly received, and hence need to be retransmitted. RRC messages are transported over the retransmission return channel. A receiver that supports retransmission will typically include a frame error detector, a rescheduling queue, and a retransmission request encoder. The frame error detector detects the correctness of each received frame. The rescheduling queue re-sequences elementary frames in the event that correctly received elementary frames are received out of order due to retransmission. The request encoder converts the decisions of the frame error detector into a RRC message, which can be understood by the transmitter side.
For improved robustness during transmission over the retransmission return channel, the request information may be encoded. Encoding, also referred to as coding, involves adding redundancy to the original message. Encoding the RRC message at the receiver side may involve some decoding capability at the transmitter side in order to be correctly interpreted by the system. One technique for encoding the redundancy bits of the RRC message has been proposed in the G.inp recommendation. Thus far, the use of a (24, 12) extended Golay code and the use of a 12 bit cyclic redundancy check (CRC-12) have been proposed to encode the 12 bits of the raw RRC message. However, questions remain regarding which code performs most effectively for G.inp environments as a number of perceived shortcomings involving current approaches to utilizing a (24, 12) Golay code and a 12-bit cyclic redundancy check (CRC-12) exist.